Pull request overview

This PR adds comprehensive support for BPF map-of-maps (BPF_MAP_TYPE_HASH_OF_MAPS and BPF_MAP_TYPE_ARRAY_OF_MAPS) to the Aya framework, building upon the foundation from PR #70.

Changes:

• Added inner attribute to #[map] macro for declaring map-of-maps templates in eBPF code
• Implemented HashMapOfMaps and ArrayOfMaps types with get(), iter(), and other helper methods
• Added support for program array population via EbpfLoader::set_prog_array_entry() and Ebpf::populate_prog_arrays()

Reviewed changes

Copilot reviewed 43 out of 43 changed files in this pull request and generated no comments.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f2593b39d1

@tamird made 3 comments.
Reviewable status: 0 of 43 files reviewed, 3 unresolved discussions (waiting on @Brskt).

-- commits line 70 at r35:
The commits in this PR are mostly a mess, but e.g. this one looks useful on its own. Did you intend for the commits history to be preserved? If yes, we will need you to rewrite it into something coherent. If not, then this PR is 3k lines that have to be reviewed in one shot, which is quite difficult.

Code quote:

New commits in r8 on 1/17/2026 at 4:21 PM:
- d1f0cb8: feat(aya): Add prog_array population support for tail calls

  Add EbpfLoader::set_prog_array_entry() to declaratively specify which
  programs should be placed in program arrays at which indices.

  Add Ebpf::populate_prog_arrays() to populate the declared entries with
  loaded program file descriptors after programs are loaded.

  This enables easier setup of tail call jump tables without manually
  managing program array entries.

@Brskt made 3 comments and resolved 2 discussions.
Reviewable status: 0 of 43 files reviewed, 1 unresolved discussion (waiting on @tamird).

-- commits line 70 at r35:

Yes, I've kept the commit history and rewritten it as requested:

1. aya-ebpf: eBPF-side map-of-maps implementation
2. aya-ebpf-macros: inner attribute for #[map] macro
3. aya-obj: Map constructors and .maps.inner parsing
4. aya: userspace map-of-maps support
5. tests: integration and unit tests
6. public API updates

Should be easier to review now.

@tamird partially reviewed 15 files and made 2 comments.
Reviewable status: 1 of 43 files reviewed, 2 unresolved discussions (waiting on @Brskt).

-- commits line 70 at r35:

it's still just one big blob, right? the commits are now cut along which crates they touch, which is maybe easier for review but they need to be squashed on merge. do I understand correctly?

ebpf/aya-ebpf/src/maps/mod.rs line 47 at r36 (raw file):

///
/// Only implement this trait for map types that can be safely used as inner maps.
pub unsafe trait InnerMap {}

🤔 does this need to be pub?

@Brskt made 2 comments.
Reviewable status: 1 of 43 files reviewed, 2 unresolved discussions (waiting on @tamird).

-- commits line 70 at r35:

Yes, that's correct. Split for easier review, feel free to squash on merge.

ebpf/aya-ebpf/src/maps/mod.rs line 47 at r36 (raw file):

I tested with pub(crate) and here's what happens:

Build results:

• cargo build: ⚠️ 3 warnings (private_bounds)
• cargo clippy -D warnings: ❌ 3 errors - fails CI
• cargo test: ✅ pass
• integration tests: ✅ 127 passed
• public-api check: ❌ fails (InnerMap removed from API)

Why it fails:
InnerMap is used as a trait bound on public types:

pub struct ArrayOfMaps<T: InnerMap> { ... }

A private trait in a public bound triggers private_bounds, which becomes an error with -D warnings.

Conclusion:
pub is required to pass CI. The unsafe marker already discourages external implementations, and the kernel validates map types at load time anyway.

@tamird partially reviewed 42 files, made 8 comments, and resolved 1 discussion.
Reviewable status: 19 of 43 files reviewed, 8 unresolved discussions (waiting on @Brskt).

ebpf/aya-ebpf/src/maps/mod.rs line 47 at r36 (raw file):

I see. This should be a sealed trait then since we don't want external implementations.

-- commits line 25 at r38:
this commit is ...bad. it's adding a bunch of code that is unused, making review impossible.

ebpf/aya-ebpf/src/maps/hash_of_maps.rs line 14 at r36 (raw file):

pub struct HashOfMaps<K, V> {
    def: UnsafeCell<bpf_map_def>,
    _k: PhantomData<K>,

See #1447; use a single phantom plz

aya-ebpf-macros/src/map.rs line 20 at r37 (raw file):

        let mut args = syn::parse2(attrs)?;
        let name = name_arg(&mut args).unwrap_or_else(|| item.ident.to_string());
        let inner = pop_string_arg(&mut args, "inner");

while you're here, please add err_on_unknown_args(args)?; (see #1448)

aya-ebpf-macros/src/map.rs line 40 at r37 (raw file):

                #[used]
                static #binding_ident: [u8; #binding_len] = [#(#binding_bytes),*];
            }

are we following libbpf conventions here? needs citations

Code quote:

            // Create a unique identifier for the binding
            let binding_ident = format_ident!("__inner_map_binding_{}", name);
            // Format: "outer_name\0inner_name\0" (null-terminated strings)
            let binding_value = format!("{}\0{}\0", name, inner);
            let binding_len = binding_value.len();
            let binding_bytes = binding_value.as_bytes();
            quote! {
                #[unsafe(link_section = ".maps.inner")]
                #[used]
                static #binding_ident: [u8; #binding_len] = [#(#binding_bytes),*];
            }

aya-ebpf-macros/src/map.rs line 42 at r37 (raw file):

            }
        } else {
            quote! {}

we can drop this b/c Options impls ToTokens

https://docs.rs/quote/latest/quote/trait.ToTokens.html#impl-ToTokens-for-Option%3CT%3E

aya-ebpf-macros/src/map.rs line 118 at r37 (raw file):

        );
        // "OUTER\0INNER_TEMPLATE\0" = 21 bytes
        assert!(expanded_str.contains("21usize"), "expected 21 bytes");

these assertions are problematic because they emit no information on failure

Code quote:

        assert!(
            expanded_str.contains(".maps.inner"),
            "expected .maps.inner section"
        );
        assert!(
            expanded_str.contains("__inner_map_binding_OUTER"),
            "expected binding identifier"
        );
        // "OUTER\0INNER_TEMPLATE\0" = 21 bytes
        assert!(expanded_str.contains("21usize"), "expected 21 bytes");

ebpf/aya-ebpf/src/maps/array_of_maps.rs line 19 at r36 (raw file):

unsafe impl<T: InnerMap> Sync for ArrayOfMaps<T> {}

impl<T: InnerMap> ArrayOfMaps<T> {

let's reduce some of this boilerplate, see #1447

@Brskt made 8 comments.
Reviewable status: 19 of 43 files reviewed, 8 unresolved discussions (waiting on @tamird).

-- commits line 25 at r38:

Done, is this the way u wanted ?

aya-ebpf-macros/src/map.rs line 20 at r37 (raw file):

Done.

aya-ebpf-macros/src/map.rs line 40 at r37 (raw file):

No, this is not following libbpf conventions. Documentation has been added to clarify this.

libbpf uses BTF relocations within the .maps section for inner map bindings (see https://patchwork.ozlabs.org/comment/2418417/), where u declare .values = { [0] = &inner_map, ... } and libbpf processes the relocations.

The .maps.inner section is an aya-specific mechanism. This approach was chosen because:

• aya-ebpf doesn't require BTF for map definitions
• It provides a simpler mechanism that works with both legacy and BTF-style maps

The format is now documented in both aya-ebpf-macros/src/map.rs and aya-obj/src/obj.rs with references to the libbpf implementation.

aya-ebpf-macros/src/map.rs line 42 at r37 (raw file):

Done.

aya-ebpf-macros/src/map.rs line 118 at r37 (raw file):

Done.

ebpf/aya-ebpf/src/maps/array_of_maps.rs line 19 at r36 (raw file):

Acknowledged. This PR can be rebased on top of #1447 once it's merged to use the MapDef abstraction, which will eliminate the duplicated UnsafeCell<bpf_map_def> wrapper, unsafe impl Sync, and constructor boilerplate.

Should I wait for #1447 to land first, or would you prefer I implement a similar pattern in this PR?

ebpf/aya-ebpf/src/maps/hash_of_maps.rs line 14 at r36 (raw file):

Done.

ebpf/aya-ebpf/src/maps/mod.rs line 47 at r36 (raw file):

Done.

Each map type now implements Sealed (e.g., impl<T> Sealed for Array<T> {}), preventing external implementations while keeping InnerMap public to satisfy the trait bounds on ArrayOfMaps<T: InnerMap> and HashOfMaps<K, V: InnerMap>.

@tamird partially reviewed 26 files, made 3 comments, and resolved 3 discussions.
Reviewable status: 3 of 43 files reviewed, 7 unresolved discussions (waiting on @Brskt).

aya-ebpf-macros/src/map.rs line 40 at r37 (raw file):

Doesn't this mean that libbpf can't load aya programs that use map-in-map, and vice versa? That's generally not the approach we have taken.

A better link: torvalds/linux@646f02ffdd49

aya-ebpf-macros/src/map.rs line 106 at r47 (raw file):

    #[test]
    fn test_map_with_inner() {

the tests above check for the exact generated code, can we follow the same style? if not, please add a comment explaining why

aya-ebpf-macros/src/map.rs line 171 at r47 (raw file):

            ),
        );
        assert!(result.is_err());

pretty weak assertion

@Brskt made 3 comments.
Reviewable status: 2 of 48 files reviewed, 7 unresolved discussions (waiting on @tamird).

aya-ebpf-macros/src/map.rs line 40 at r37 (raw file):

Done. #[btf_map] with btf_maps::ArrayOfMaps/HashOfMaps now works with both aya and libbpf loaders (tested both). Uses [*const V; 0] for the values field per the BTF relocation format libbpf expects.

Legacy #[map(inner = "...")] remains aya-specific but is now documented as such.

Does this address your concern ?

aya-ebpf-macros/src/map.rs line 106 at r47 (raw file):

Done.

aya-ebpf-macros/src/map.rs line 171 at r47 (raw file):

Done.

@tamird partially reviewed 41 files and made 2 comments.
Reviewable status: 2 of 48 files reviewed, 9 unresolved discussions (waiting on @Brskt).

ebpf/aya-ebpf/src/btf_maps/array.rs line 11 at r53 (raw file):

///
/// This map type stores elements of type `T` indexed by `u32` keys.
/// The struct layout is designed to be compatible with both aya and libbpf loaders.

what does that mean?

ebpf/aya-ebpf/src/btf_maps/array.rs line 23 at r53 (raw file):

#[repr(C)]
#[allow(dead_code)]
pub struct Array<T, const M: usize, const F: usize = 0> {

why did we need to toss bpf_map_def!?

@Brskt made 2 comments.
Reviewable status: 2 of 48 files reviewed, 9 unresolved discussions (waiting on @tamird).

ebpf/aya-ebpf/src/btf_maps/array.rs line 11 at r53 (raw file):

I've improved the comments. Is it clearer now ?

ebpf/aya-ebpf/src/btf_maps/array.rs line 23 at r53 (raw file):

The existing btf_maps that use btf_map_def! (RingBuf, SkStorage) aren't libbpf-compatible either - they only work with aya's loader. For this PR, you requested that map-of-maps be loadable by both aya and libbpf, so I used flat #[repr(C)] structs instead.

@tamird made 1 comment.
Reviewable status: 2 of 48 files reviewed, 9 unresolved discussions (waiting on @Brskt).

ebpf/aya-ebpf/src/btf_maps/array.rs line 23 at r53 (raw file):

Ah, yeah this is also #1455. Would you be willing to send a separate PR to fix that for all the maps?

@Brskt made 1 comment.
Reviewable status: 2 of 48 files reviewed, 9 unresolved discussions (waiting on @tamird and @vadorovsky).

ebpf/aya-ebpf/src/btf_maps/array.rs line 23 at r53 (raw file):

Done in #1457

@tamird reviewed 29 files and all commit messages, made 20 comments, and resolved 8 discussions.
Reviewable status: 50 of 53 files reviewed, 20 unresolved discussions (waiting on alessandrod, Brskt, and vadorovsky).

aya/src/maps/of_maps/array.rs line 154 at r111 (raw file):

still here isn't it?

aya/src/maps/mod.rs line 107 at r112 (raw file):

///
/// This is used by map-of-maps types ([`ArrayOfMaps`], [`HashOfMaps`]) to
/// let callers specify the expected inner map type when retrieving entries.

this description does not seem correct

Code quote:

/// This is used by map-of-maps types ([`ArrayOfMaps`], [`HashOfMaps`]) to
/// let callers specify the expected inner map type when retrieving entries.

aya/src/maps/mod.rs line 117 at r112 (raw file):

impl<T: sealed::FromMapData> FromMapData for T {
    fn from_map_data(map_data: MapData) -> Result<Self, MapError> {
        <Self as sealed::FromMapData>::from_map_data(map_data)

if the supertrait already has this method then why do we need it on the subtrait + this trampoline?

aya/src/maps/mod.rs line 124 at r112 (raw file):

///
/// Types implementing this trait can be passed to
/// [`ArrayOfMaps::set`] and [`HashOfMaps::insert`].

this comment is stale since those functions now take the outer map's V

Code quote:

/// Types implementing this trait can be passed to
/// [`ArrayOfMaps::set`] and [`HashOfMaps::insert`].

aya/src/maps/mod.rs line 129 at r112 (raw file):

pub trait InnerMap: sealed::InnerMap {
    /// Returns the map file descriptor.
    fn fd(&self) -> &MapFd;

ditto, why do we need this trampoline?

aya/src/maps/mod.rs line 164 at r112 (raw file):

    MissingInnerMapBinding {
        /// The map name.
        name: String,

can this be outer_name to avoid ambiguity? ditto below on InnerMapNotFound

aya/src/maps/mod.rs line 291 at r112 (raw file):

    }

    /// Creates a new instance that shares the same underlying file description as `self`.

👏 props to claude for knowing the difference between descriptor and description here.

aya/src/maps/mod.rs line 641 at r112 (raw file):

});

// ArrayOfMaps and HashOfMaps need an unconstrained V in TryFrom conversions.

unconstrained, why? shouldn't it be constrained to InnerMap?

aya/src/maps/mod.rs line 660 at r112 (raw file):

// Implements `sealed::FromMapData` for map types that the kernel supports as inner maps.
// Excluded: ProgramArray (no map_meta_equal), ArrayOfMaps/HashOfMaps (multi-level nesting
// forbidden).

from the midway point of the first sentence until the end of this comment, it is describing the invocation (below) rather than the macro.

Code quote:

// Implements `sealed::FromMapData` for map types that the kernel supports as inner maps.
// Excluded: ProgramArray (no map_meta_equal), ArrayOfMaps/HashOfMaps (multi-level nesting
// forbidden).

aya/src/maps/mod.rs line 684 at r112 (raw file):

});

// PerfEventArray and RingBuf use a different field layout, so InnerMap is

but don't they all have map_data()? couldn't you use this shape for all of them?

aya/src/maps/mod.rs line 721 at r112 (raw file):

        Ok(map_data)
    }
}

erhm, why?

Code quote:

impl sealed::FromMapData for MapData {
    fn from_map_data(map_data: MapData) -> Result<Self, MapError> {
        Ok(map_data)
    }
}

aya/src/maps/mod.rs line 733 at r112 (raw file):

        self
    }
}

why?

Code quote:

impl sealed::InnerMap for MapData {
    fn inner_map_fd(&self) -> &MapFd {
        self.fd()
    }
}

impl sealed::InnerMap for MapFd {
    fn inner_map_fd(&self) -> &MapFd {
        self
    }
}

aya/src/maps/mod.rs line 777 at r112 (raw file):

    PerCpuHashMap(BPF_MAP_TYPE_PERCPU_HASH, size_of::<K>() as u32, V, "standalone_percpu_hash"),
    LpmTrie(BPF_MAP_TYPE_LPM_TRIE, size_of::<lpm_trie::Key<K>>() as u32, V, "standalone_lpm_trie"),
});

this feels like significant coupling at a distance. in other words, the types and constants encoded here need to match these same ones encoded in the implementation of each map. can we avoid this fragile duplication?

Code quote:

// Implements `create()` for map types that can be created standalone for use as inner maps in
// map-of-maps. Each invocation specifies the kernel map type, key size expression, the type
// parameter used for value size, and a name for the created map.
macro_rules! impl_create_map {
    ($ty_param:tt {
        $($ty:ident($map_type:ident, $key_size:expr, $val:ident, $name:literal)),+ $(,)?
    }) => {
        $(impl_create_map!(<$ty_param> $ty($map_type, $key_size, $val, $name));)+
    };
    (<($($ty_param:ident),+)> $ty:ident($map_type:ident, $key_size:expr, $val:ident, $name:literal)) => {
        impl<$($ty_param: Pod),+> $ty<MapData, $($ty_param),+> {
            /// Creates a standalone map, not loaded from an eBPF object file.
            ///
            /// This is useful for creating inner maps to insert into map-of-maps
            /// types like [`ArrayOfMaps`](crate::maps::ArrayOfMaps) or
            /// [`HashOfMaps`](crate::maps::HashOfMaps).
            pub fn create(max_entries: u32, flags: u32) -> Result<Self, MapError> {
                let obj = aya_obj::Map::new_legacy(
                    aya_obj::generated::bpf_map_type::$map_type as u32,
                    $key_size,
                    size_of::<$val>() as u32,
                    max_entries,
                    flags,
                );
                Self::new(MapData::create(obj, $name, None)?)
            }
        }
    };
}

impl_create_map!((V) {
    Array(BPF_MAP_TYPE_ARRAY, size_of::<u32>() as u32, V, "standalone_array"),
    PerCpuArray(BPF_MAP_TYPE_PERCPU_ARRAY, size_of::<u32>() as u32, V, "standalone_percpu_array"),
    BloomFilter(BPF_MAP_TYPE_BLOOM_FILTER, 0, V, "standalone_bloom_filter"),
    Queue(BPF_MAP_TYPE_QUEUE, 0, V, "standalone_queue"),
    Stack(BPF_MAP_TYPE_STACK, 0, V, "standalone_stack"),
});

impl_create_map!((K, V) {
    HashMap(BPF_MAP_TYPE_HASH, size_of::<K>() as u32, V, "standalone_hash"),
    PerCpuHashMap(BPF_MAP_TYPE_PERCPU_HASH, size_of::<K>() as u32, V, "standalone_percpu_hash"),
    LpmTrie(BPF_MAP_TYPE_LPM_TRIE, size_of::<lpm_trie::Key<K>>() as u32, V, "standalone_lpm_trie"),
});

aya-ebpf-macros/src/map.rs line 29 at r112 (raw file):

        let item = &self.item;

        // Aya-specific mechanism for inner map bindings (legacy, NOT libbpf-compatible).

can we just take the same approach as libbpf and NOT support legacy maps-in-maps?

aya-obj/src/maps.rs line 287 at r112 (raw file):

    ///
    /// This is useful for creating inner maps dynamically for map-of-maps types.
    pub const fn new_legacy(

reminder to remove if we agree not to support legacy maps of maps

aya-obj/src/obj.rs line 902 at r112 (raw file):

    }

    /// Parses the `.maps.inner` section which contains outer->inner map bindings.

same comment here as elsewhere (and reminder to remove associated error types if we agree)

ebpf/aya-ebpf/src/maps/array_of_maps.rs line 66 at r112 (raw file):

    /// Same as [`get_value`](Self::get_value) but returns a mutable pointer.
    #[inline(always)]
    pub fn get_value_ptr_mut(&self, outer_index: u32, inner_key: &T::Key) -> Option<*mut T::Value> {

here and in the hash map - why return a mut pointer rather than a mut ref?

test/integration-ebpf/src/btf_map_of_maps.rs line 21 at r112 (raw file):

// The inner map definition is parsed from the BTF `values` field at load time.
#[btf_map]
static OUTER: ArrayOfMaps<Array<u32, 10>, 4> = ArrayOfMaps::new();

probably no longer makes sense to call this OUTER?

test/integration-ebpf/src/btf_map_of_maps.rs line 25 at r112 (raw file):

// Result array to verify values from userspace.
#[btf_map]
static RESULTS: Array<u32, 4> = Array::new();

why 4? why not an array of 1 element containing a structure?

test/integration-ebpf/src/btf_map_of_maps.rs line 31 at r112 (raw file):

#[expect(
    clippy::missing_const_for_fn,
    reason = "extern functions cannot be const"

uh, i think this is is not true. it can be const

@Brskt made 17 comments.
Reviewable status: 50 of 53 files reviewed, 20 unresolved discussions (waiting on alessandrod, tamird, and vadorovsky).

aya/src/maps/mod.rs line 107 at r112 (raw file):

Removed.

aya/src/maps/mod.rs line 117 at r112 (raw file):

Done, from_map_data now lives only on the sealed supertrait.

aya/src/maps/mod.rs line 124 at r112 (raw file):

Removed.

aya/src/maps/mod.rs line 129 at r112 (raw file):

Done, same as FromMapData, removed the trampoline, renamed inner_map_fd to fd on the sealed supertrait.

aya/src/maps/mod.rs line 164 at r112 (raw file):

Done, renamed to outer_name.

aya/src/maps/mod.rs line 641 at r112 (raw file):

It can, constrained V to InnerMap in the TryFrom impls.

aya/src/maps/mod.rs line 660 at r112 (raw file):

Done, moved the exclusion list to the invocation site.

aya/src/maps/mod.rs line 684 at r112 (raw file):

Not all map types have map_data(), only PerfEventArray and RingBuf (different field layout: Arc<T> / T vs inner: T). Unifying would mean adding map_data() to all map types. Want me to do that here or in a follow-up?

aya/src/maps/mod.rs line 721 at r112 (raw file):

It allows get() to work with the default V = MapData, returning an untyped handle for introspection (info(), pin(), fd()). If this not worth keeping, I can remove it.

aya/src/maps/mod.rs line 733 at r112 (raw file):

InnerMap for MapFd is used in integration tests for the lightweight set(&fd) pattern. InnerMap for MapData allows passing a raw MapData to set()/insert() without extracting the fd first. Same story as FromMapData, same as the upper comment.

aya/src/maps/mod.rs line 777 at r112 (raw file):

The map type and key size are duplicated between create() and each map's new() validation. I could move create() into each map module next to new(), or use a trait with associated constants to centralize the logic. What do you prefer?

aya/src/maps/of_maps/array.rs line 154 at r111 (raw file):

Removed.

aya-ebpf-macros/src/map.rs line 29 at r112 (raw file):

The maps-in-maps BTF need Kernel 5.7+ to work. Do we keep it and support for the olders versions (since 4.12) or remove so the user will require this minimum version?

ebpf/aya-ebpf/src/maps/array_of_maps.rs line 66 at r112 (raw file):

This follows the existing pattern, Array::get_ptr_mut, HashMap::get_ptr_mut, and PerCpuArray::get_ptr_mut all return *mut T rather than &mut T. Returning &mut from &self would be an aliasing violation since two calls with the same key would produce two &mut to the same memory. The raw pointer leaves safety responsibility to the caller via unsafe.

test/integration-ebpf/src/btf_map_of_maps.rs line 21 at r112 (raw file):

Renamed.

test/integration-ebpf/src/btf_map_of_maps.rs line 25 at r112 (raw file):

Done.

test/integration-ebpf/src/btf_map_of_maps.rs line 31 at r112 (raw file):

Yup, it can be, done.

@tamird reviewed 13 files and all commit messages, made 6 comments, resolved 11 discussions, and dismissed @alessandrod from a discussion.
Reviewable status: 51 of 54 files reviewed, 9 unresolved discussions (waiting on alessandrod, Brskt, and vadorovsky).

aya/src/maps/mod.rs line 684 at r112 (raw file):

I think doing it here would make sense (i believe I suggested that via macro in an earlier comment thread)

aya/src/maps/mod.rs line 733 at r112 (raw file):

do we actually want people doing this? if not and it's just a shortcut for the tests, i think we'd better remove it

aya/src/maps/mod.rs line 777 at r112 (raw file):

centralized logic is good and a trait is better than a macro

aya/src/maps/of_maps/array.rs line 154 at r111 (raw file):

ArrayOfMaps::new, no need for turbofish when it's all underscores

aya-ebpf-macros/src/map.rs line 29 at r112 (raw file):

We don't even have CI coverage before 5.10, so I think it's OK to have the same version requirements as libbpf.

ebpf/aya-ebpf/src/maps/array_of_maps.rs line 66 at r112 (raw file):

OK. This ofc stinks because we should just take &mut self but we can solve this separately

@Brskt made 7 comments.
Reviewable status: 51 of 54 files reviewed, 9 unresolved discussions (waiting on alessandrod, tamird, and vadorovsky).

aya/src/maps/mod.rs line 684 at r112 (raw file):

do we actually want people doing this? if not and it's just a shortcut for the tests, i think we'd better remove it

aya/src/maps/mod.rs line 733 at r112 (raw file):

To clarify my previous answer: it's not just a test shortcut, the tests demonstrate a real use case. When inner maps come from Ebpf::map(), you can't borrow the inner and outer maps at the same time. The only way around it is cloning the fd:

let inner_fd = ebpf.map("INNER").unwrap().fd().try_clone().unwrap();
let mut outer: ArrayOfMaps<&mut MapData, MapFd> = ebpf.map_mut("OUTER").unwrap().try_into().unwrap();
outer.set(0, &inner_fd, 0).unwrap();

Without InnerMap for MapFd, users have no way to insert loaded maps into a map-of-maps.

aya/src/maps/mod.rs line 777 at r112 (raw file):

Done. Replaced the macro body with a pub(super) trait CreatableMap in mod sealed that holds the associated constants and a provided create() method. The macro is now a thin wrapper that generates inherent create() methods delegating to the trait.

aya/src/maps/of_maps/array.rs line 154 at r111 (raw file):

Done. Extracted the call into a typed let binding to avoid the turbofish.

aya-ebpf-macros/src/map.rs line 29 at r112 (raw file):

Done. Removed legacy map-of-maps support entirely.

aya-obj/src/maps.rs line 287 at r112 (raw file):

Removed.

aya-obj/src/obj.rs line 902 at r112 (raw file):

Removed.

@tamird reviewed 20 files and all commit messages, made 5 comments, and resolved 4 discussions.
Reviewable status: 52 of 55 files reviewed, 7 unresolved discussions (waiting on alessandrod, Brskt, and vadorovsky).

aya/src/maps/mod.rs line 684 at r112 (raw file):

?

aya/src/maps/of_maps/array.rs line 154 at r111 (raw file):

I think I don't understand why any of this ascription is needed, can't you just write ArrayOfMaps::new(&map)?

aya-obj/src/maps.rs line 287 at r112 (raw file):

not?

aya/src/maps/mod.rs line 133 at r114 (raw file):

    }

    pub(super) trait CreatableMap: Sized {

not pub, so needn't be in the sealed module. right?

aya/src/maps/mod.rs line 805 at r114 (raw file):

        impl<$($param: Pod),*> $ty<MapData, $($param),*> {
            /// Creates a standalone map with the given `max_entries` capacity and `flags`.
            pub fn create(max_entries: u32, flags: u32) -> Result<Self, MapError> {

why do we need both the trait method and the inherent method? maybe the trait should be sealed after all

@Brskt made 5 comments.
Reviewable status: 48 of 55 files reviewed, 7 unresolved discussions (waiting on alessandrod, tamird, and vadorovsky).

aya/src/maps/mod.rs line 684 at r112 (raw file):

How did this sentence end up there?

Should be:
Done, added a via $accessor arm to impl_from_map_data so PerfEventArray and RingBuf use the macro instead of manual impls.

aya/src/maps/mod.rs line 133 at r114 (raw file):

Right, moved CreatableMap out of sealed, it's pub(super) so it doesn't need the sealed pattern.

aya/src/maps/mod.rs line 805 at r114 (raw file):

Done, moved CreatableMap into sealed with a public wrapper, same pattern as FromMapData and InnerMap. No more duplicate inherent method.

aya/src/maps/of_maps/array.rs line 154 at r111 (raw file):

The annotations are required, the default V = MapData isn't used when the compiler needs to resolve trait bounds (InnerMap, FromMapData). Without them, rustc can't infer V.

aya-obj/src/maps.rs line 287 at r112 (raw file):

Actually, we need them. renamed new_legacy to new_from_params since the name was misleading since it's not about legacy map definitions. It's used by CreatableMap::create() to build inner maps programmatically from raw parameters (type, key_size, value_size, max_entries). Without it, userspace has no way to create inner maps to insert into map-of-maps slots.

@tamird reviewed 7 files and all commit messages, made 4 comments, and resolved 5 discussions.
Reviewable status: all files reviewed, 4 unresolved discussions (waiting on alessandrod, Brskt, and vadorovsky).

aya/src/maps/of_maps/array.rs line 154 at r111 (raw file):

If you can't just write ArrayOfMaps::new then the previous form (ArrayOfMaps::<_>::new) is better

aya-obj/src/maps.rs line 287 at r112 (raw file):

does it need to be pub?

aya/src/maps/mod.rs line 125 at r116 (raw file):

pub trait CreatableMap: sealed::CreatableMap {
    /// Creates a standalone map with the given `max_entries` capacity and `flags`.
    fn create(max_entries: u32, flags: u32) -> Result<Self, MapError> {

LLM loves the trampolines, huh?

ebpf/aya-ebpf/src/btf_maps/mod.rs line 45 at r116 (raw file):

#[inline(always)]
pub(crate) unsafe fn lookup_inner<'a, K, V>(
    inner_map: core::ptr::NonNull<core::ffi::c_void>,

we can't make this generic over InnerMap? ditto below

@Brskt made 4 comments.
Reviewable status: 48 of 55 files reviewed, 4 unresolved discussions (waiting on alessandrod, tamird, and vadorovsky).

aya/src/maps/mod.rs line 125 at r116 (raw file):

Wasn't really in the audit, added now and hope it doesn't do it again.

Now, removed the trait entirely. create() is now a direct inherent method on each type via impl_creatable_map macro.

aya/src/maps/of_maps/array.rs line 154 at r111 (raw file):

Alright, reverted.

aya-obj/src/maps.rs line 287 at r112 (raw file):

It's called from the aya crate (impl_creatable_map macro), and aya-obj is a separate crate, so it needs to be pub.

ebpf/aya-ebpf/src/btf_maps/mod.rs line 45 at r116 (raw file):

Yes, changed to M: private::MapDef which carries Key and Value as associated types.

@tamird reviewed 1 file and all commit messages, made 2 comments, and resolved 2 discussions.
Reviewable status: 49 of 55 files reviewed, 2 unresolved discussions (waiting on alessandrod, Brskt, and vadorovsky).

aya/src/maps/mod.rs line 125 at r116 (raw file):

wait, what? I was just saying that this method is already on the inner sealed trait.

ebpf/aya-ebpf/src/btf_maps/mod.rs line 45 at r116 (raw file):

but why is inner_map a type-erased pointer rather than a reference or at least a typed pointer?

@Brskt made 2 comments.
Reviewable status: 49 of 55 files reviewed, 2 unresolved discussions (waiting on alessandrod, tamird, and vadorovsky).

aya/src/maps/mod.rs line 125 at r116 (raw file):

Oh, I misunderstood. Do you want me to revert that change or is this one OK?

ebpf/aya-ebpf/src/btf_maps/mod.rs line 45 at r116 (raw file):

It was an oversight. Changed to NonNull<M>.

@tamird made 2 comments.
Reviewable status: 49 of 55 files reviewed, 2 unresolved discussions (waiting on alessandrod, Brskt, and vadorovsky).

aya/src/maps/mod.rs line 125 at r116 (raw file):

The trait is better than giving each one an inherent method, I think.

ebpf/aya-ebpf/src/btf_maps/mod.rs line 45 at r116 (raw file):

i think you can revert the type ascription in the callers now